It is known that, by exchanging suitable bus messages, bus nodes such as stations that are part of a partial network, such as bus system, can request each other to change between different states of operation, particularly a sleep (or quiescent mode) and a normal mode. Such systems, which are for example subject to the CAN (controller area network) protocol or the LIN (local interconnect network) protocol, or FlexRay protocol (which is a known next generation vehicular network that is described in publicly-available documents and at the FlexRay Internet website)” are typically employed in motor or automotive vehicles, in which there is a steady need for reduction of the electrical energy consumption. Even when the vehicle is parked and not operating, individual stations have to be woken up at regular intervals or upon irregular events to perform individual functions. As well as it is being possible for a change to be made between the sleep mode and the normal mode, it is also desirable for this change to be able to be made selectively, i.e. for individual stations to be able to be actuated separately.
The controller area network (CAN) or the CAN-bus, as one example for the herein addressed communication networks, is a vehicle communication bus standard designed to allow microcontrollers to communicate with each other within a vehicle. The (bus) protocol controllers connected by the CAN-bus are exchanging typically sensor data, actuator commands, service data and the like.
Further, the CAN protocol is a message based protocol, designed specifically for automotive applications but which may also be used in other areas such as different types of vehicles, industrial automation and medical equipment. The CAN protocol is standardized in ISO 11898-1 (2003).
Each bus node is able to send and receive bus messages, but not simultaneously. A CAN bus message consists primarily of an ID, which may be chosen to identify the bus message-type and/or sender, and up to eight message bytes. The bus message bit sequence is transmitted serially onto the bus, one bit after another, i.e. the signal pattern codes the bus message, e.g. in non-return-to-zero (NRZ) coded manner, and is sensed by all bus nodes.
A CAN bus message never reaches these (bus) protocol controllers at the bus nodes directly. The protocol controllers are always connected via a transceiver to the bus. The transceiver may be integrated into a system basis chip, an ASIC or into the protocol controller device. If the bus is free, any bus node may begin to transmit. If two or more bus nodes begin sending bus messages at the same time, the message with the more dominant ID, e.g. which comprises more leading dominant bits, i.e., bit “0”, will overwrite other nodes' less dominant IDs. As a result, only the message with the dominant ID remains on the bus and is received by all bus nodes.
Each bus node requires at least a microcontroller unit (MCU) as host processor, the (bus) protocol controller, and the transceiver, which may be integrated all together in the same unit. However, it will be appreciated that it is also possible to have a separate transceiver unit coupled to a separate MCU, whilst the (bus) protocol controller may be a separate unit or integrated in the transceiver or in the MCU, as well.
The (bus) protocol controller, which may simply be hardware with a synchronous clock, is configured for receiving and sending. In receiving, the (bus) protocol controller stores received bits (one by one) from the bus until an entire bus message is available, which can then be fetched by the MCU, e.g. after the (bus) protocol controller has triggered an interrupt. The MCU decides what received bus messages mean and which messages it wants to transmit itself. Sensors, actuators and control devices can be connected to the MCU. In sending, the MCU transfers a transmit messages into the (bus) protocol controller, which encodes and sends the bits serially via the transceiver onto the bus. In sending, the transceiver converts the digital transmit-bit signal received from the (bus) protocol controller into an analog signal that is sent onto the bus. In receiving, the transceiver adapts signal levels from the bus to levels that the (bus) protocol controller expects and has protective circuitry that protect the (bus) protocol controller.
There is a trend for functionalities in the application layer of the communication protocol, which are normally implemented in software, to be mapped into hardware by improving the hardware. The intention in so doing is to relieve the load on the MCU; in this case, when the bus node is not needed, the entire bus node may be switched off, except for the transceiver to save a significant amount of energy and thus to avoid CO2 as well. Wake-up pattern detection is then used to recognize the point in time when the bus node is needed again.
WO 01/20434 describes a method of reducing current consumption in a CAN host processor in which a large part of the processor is set to a sleep mode and incoming CAN bus messages are analyzed by suitable hardware, and if an appropriate wake-up bus message is identified the processor is woken up. A disadvantage is the fact that, for individual stations to be selectively woken, wake-up bus messages have to be decoded, for which purpose the part of the bus node that is on standby at the relevant point in time has to have an accurate timer mechanism, which consumes energy. It would be particularly desirable if, when a station was in the sleep mode, the transceiver could independently receive and analyze data transmitted on the bus line, particularly to enable it to decide whether its own bus node has to be woken up.
WO2006/003540A1 describes a solution for detecting wake-up bus messages in a CAN system. However, the described bus message detector may still react to many bus messages that have a bit pattern similar to the target bit pattern. This leads still to unwanted wake-up events, which can use power unnecessarily.
A further problem with known wake-up patterns is that the defined wakeup patterns do not allow for addressing different wakeup-groups and there is no definition of IDs and priorities to be used.
It is therefore an object of the invention to provide a more reliable method to detect “wake-up bus messages” in a stream of bus messages. In particular, it is an object to specify a method that enables a bus node or functionality of the bus node, such as a transceiver or a separate unit to independently receive and analyze the data transmitted on the bus. More particular, it is an object to provide an improved wake-up functionality, which result in more reliability in situations where a bus node or a sub-network is to be woken individually by means of a given wake-up bus message.
It is a further object to provide an improved wake-up bus message detector for a bus node. In particular, it is an object to enable the bus node to detect wake-up bus messages even when that part of the bus node that shall detect the wake-up bus message does not have an accurate timer and also does not have any knowledge of the bit rate at which the data is transmitted on the bus.